Introdução
a gestão dos patches permitem integrar os elementos do dicionário a partir de um arquivo, em respeitando :
- Os códigos actividades específicas e verticais (ie aqueles començando por X, Y, ou Z, excepto se fazem parte da lista explicita dada em cabeçalho de patch para permitir modificar os elementos específicos).
- certos campos de um elemento colocado em patch considerados como fazendo parte da parametrização. Estes campos são susceptíveis de serem modificados pelo utilizador, e não são então modificados no momento de um patch contendo um elemento já existente (bem entendido, a primeira vez que o elemento está integrado numa patch, estes elementos são integrados para permitir de dispor de um valor por defeito).
Isto significa que uma vez um elemento integrado numa patch certos campos deste elemento não determina deste elemento não são mais modificáveis por patch. A única solução, se deseja absolutamente modificar um elemento, está então de colocar em patch um tratamento modificando os dados, e de executar em sequência (o que é possível via o tipo de elemento EXE).
É enfim de notar
- que os campos CREDAT e CREUSR (se existem na estrutura do dicionário impactado pelo patch) são atualizados em caso de criação de um novo elemento.
- que os campos UPDDAT e UPDUSR (se existem na estrutura do dicionário impactado pelo patch) são atualizados em caso de modificação de um novo elemento.
- que o patch de dados numa tabela não coberta pela lista standard actualiza os dados sem filtro sobre os campos.
Isto sendo dito, encontrar-se-á na seguinte, para cada tipo de elemento impactado, a lista dos campos que não são atualizados por patch em caso de atualização.
Regras gerais
O utilitário de patch permite de colocar em patch :
- um conjunto de elementos de tipo desenvolvimento (são os tratamentos, e todos os elementos do dicionário : tipos, descrição de tabelas, ecrãs, janelas, ações...) Estas patches são identificadas por um código correspondente ao objeto de colocação em patch.
À parte os tratamentos, que não são instalados que no dossier raíz (X3 para Enterprise Management), e nos casos dos dossiers marcados "de teste", todos os outros elementos são atualizados nos diferentes dicionários dos dossiers colocados em patches, com um filtro tendo em conta os códigos artividades presentes sobre os diferentes elementos. Assim, um elemento protegido por um código atividade específico não será atualizado por um patch standard. - um conjunto de elementos de tipo parametrização que têm um código atividade na sua definição (processo, modelos de importação-exportação, eventos Workflow nomeadamente). Neste caso, a mesma regra se aplica, quer dizer que a presença de um código atividade especifico permite proteger estes elementos de um patch standard.
- um conjunto de elementos de tipo parametrização que não têm um código de atividade na sua definição. Neste caso, o patch se aplica sobre os dossiers sobre os quais foi instalado, e estas parametrizações são sempre substituidas pelo conteúdo do patch. É nomeadamente o caso para os pedidos, os planos de trabalho Workflow... É recomendado, se deseja proteger os elementos standard modificados, de os renomear afim de evitar de os ver destruidos no caso onde um patch os modificará (o que é assim mesmo raro).
- um conjunto de dados de uma parametrização (baseada sobre a função definido os modelos de parametrização). No caso particular, a aplicação destes patches (codificadas AAA) se faz em tendo a conta à vez de filtros ligados a códigos atividades (se existem nas tabelas colocadas em patch), e de filtros de legislação (se um campo legislação existe no modelo de parametrização, unicamente os dados associados a uma legislação vazia ou a uma legislação presente no dossier são aplicados).
- das patches de dados genéricos. Estas patches são identificadas por abreviação da tabela que deve ser colocada em patch. Desde logo que uma abreviação de tabela não corresponde a um tipo predefinido de patches, o supervisor considera que se trata de dados colocados numa tabela. Este tipo de patches se aplica sem nenhum filtro de código atividade.
- enfim, o caso particular dos documentos automárticos (GAU) merece ser notado. Estes elementos não são colocados em patch que no dossier de raíz e nos dossiers de tipo teste, mas nunca num dossier de exploração. Pertence às pessoas em carga da parametrização de comparar os documentos automaticos do dossier X3 e aquelas do dossier de exploração antes de copiar ou de transferir as modificações feitas, se for caso disso.
Patch das ações
O campo SPETRT (tratamento específico) não está reactualizado por um patch standard. Não é que para um patch específico
Patch dos códigos actividades
Os códigos atividades são colocados na tabela ACTIV, e seu igualmente criados nos parâmetros de cada dossier (tabela ADOSACT) na lista na qual são entregues (activo ou não segundo o caso). Isto não arrasta para tanto a revalidação dos dossiers em questão.
Patch das tabelas diversas
A parametrização das tabelas diversas (tabela ATABTAB) pode ser colocada em patch como em actualização. Os campos código de acesso (ACS), comprimento código (LNG), tabela de dependência (DEPNUM), intuitulados (LNGDES e SHODES) não são colocados em dia.
Em integração de patch do conteúdo de uma tabela diversa (tabela ATABDIV), as linhas são actualizadas sem restrição.
Patch dos parâmetros
Apenas o campo de código acesso (ACS) não está reatualizado.
Patch dos ecrãs
Quando o patch é de tipo standard, as acções específicas ou verticais (SPE,SPV, código acção >=X) são sempre guardadas, assim que o tratamento específico (TRTSPE) e vertical (TRTSPV).
Para suprimir ou modificar as acções específicas (SPE), ou o tratamento específico (TRTSPE), o patch deve ser de tipo específico; para suprimir ou modificar as ações verticais (SPV), ou o tratamento vertical (TRTSPV), o patch deve ser de tipo vertical.
Por outro lado, são considerados como da parametrização não atualizados em caso de patch integrado sobre um ecrã já existente, os campos seguintes :
- sobre as linhas de ecrã : CODACC (código de acesso), CODCTL (tabela de controlo), STYZON, STYCND, INTSTYL (estilos).
- sobre o cabeçalho de ecrã : Os campos NBRCOL e NBRLIG (dimensões) são protegidos na condição que existe ao menos um código de atividade específica sobre o ecrã (sobre uma zona ou um bloco). Senão, o ecrã está considerado como standard e pode ver a sua dimensão carregar ao próximo patch.
Os blocos e linhas protegidas por um código de atividade não são impactadas.
As palavras-chaves de ajuda são respeitadas, excepto se o patch está específico e que as palavras-chaves em questão começam por X,Y ou Z.
Patch des fenêtres
Os ecrãs específicos incluidos numa janela não são impactados em caso de atualização (exceto bem entendido se seu o código actividade que os proteje está referenciado no patch).
Patch dos objetos
Os campos seguintes, considerados como de parametrização, não são actualizados em caso de patch de um objecto existente : SELCLE (índice), SELORD (ordem), SELTREE (lista hierarquizada), SELCAR (número de caracteres por selecção), RPT1, RPT2 (listas associadas), LIBSHO (título curto), STA (estatisticas). As tabelas abertas em específico são igualmente respeitadas (excepto bem entendido se o código actividade que os protege está referenciado no patch).
O campo SPETRT (tratamento específico) não está reactualizado por um patch standard. Não é que para um patch específico
O campo SPVTRT (tratamento vertical) não está reatualizado por um patch standard. Não é que para um patch vertical.
Patch das listas
Os campos seguintes, considerados como de parametrização, não são reatualizados em caso de patch de uma lista (dicionário) já existente : GRP (grupo), ACS (código de acesso), PRTNAT (tipo de destino), PRTDEF(destino por defeito), PRTOBL (flag destino obrigatório), PRTFRM (fórmula destino), ENAFLG (flag ativa), PARSEG (parâmetro de segmentação), EXEBAT (flag de execução batch), HOR (constrangimentos horário).
O campo SPETRT (tratamento específico) não está reactualizado por um patch standard. Não é que para um patch específico
O campo SPVTRT (tratamento vertical) não está reatualizado por um patch standard. Não é que para um patch vertical.
Patch das tabelas
Em caso de patch de uma estrututra de tabela existente (ATB), os elementos seguintes não são atualizados :
- O número de registo (NBENREG)
- A check box a assinalar afectando os textos traduzíveis (GENTRA) está atualizada se o patch impõe um valor igual a 2.
- Os campos relativos à auditoria (AUDCRE, AUDUPD, AUDDEL, AUDWRK no cabeçalho, assim que o conteúdo da tabela ATABAUD).
Patch das consultas
Apenas o campo PRGSPE (tratamnto específico) não está colocado em dia excepto sobre o patch específico
Patch das fórmulas de expurgos
Os campos EPU, TIM1, TIM2, FRQ1, FRQ2, DAT1, DAT2 não estão reatualizados em caso de patch de uma fórmula de expurgo (trata-se das regras e frequências de expurgo e de arquivo). Os campos ENAFLG (flag activa) estão igualmente respeitados.
O campo SPETRT (tratamento específico) não está reactualizado por um patch standard. Não é que para um patch específico
Patch das navegações
Apenas o campo ENAFLG (flag activa) não estão reatualizados.
Patch dos módulos de importação/exportação
Apenas o campo CHRNUM (número de crono exportação) não está reatualizada.
Patch dos elementos BI
Os campos seguintes, considerados como de parametrização, não são reactualizados em caso de patch:
- Patch Datamart(ABM) : RESULT(Resultado),DUREE(duração),AUZFCY(Autorização estabelecimento),FNC(Função)
- Patch Dimensão (ABI) : TYPMAJ (Tipo de actualização)
- Patch Lista BO (ABO) : ACS (Código de acesso)
